Fix of shrinking volumes with QCOW2 format#5225
Conversation
If the volumes are with QCOW2 format the shrinking will be handled on the agents side. There are cases in some storage plugins where the volumes' format is kept in the DB in QCOW2 but the actual format is raw. Till the current implementation this was limiting the plugins to shrink the volumes. Now this will be handled by the storage plugins
|
@slavkap Thanks! let me check, i come back. which version? |
|
@blueorangutan package |
|
@shwstppr a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔️ el7 ✔️ el8 ✔️ debian. SL-JID 627 |
|
@blueorangutan test |
|
@shwstppr a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
Trillian test result (tid-1352)
|
svenvogel
left a comment
There was a problem hiding this comment.
Tested with Managed Storage in our Test Environment. LGTM!
|
@shwstppr can you check and a do a forward merge to main? we need this in main too. |
shwstppr
left a comment
There was a problem hiding this comment.
LGTM. Reverts #4679
@nvazquez @sureshanaparti okay to merge?
|
|
||
| } catch (Exception e) { | ||
| throw new CloudRuntimeException("Exception caught during resize volume operation of volume UUID: " + volume.getUuid(), e); | ||
| throw new CloudRuntimeException(String.format("Failed to resize volume operation of volume UUID: [%s] due to - %s", volume.getUuid(), e.getMessage())); |
There was a problem hiding this comment.
Can you include the exception e as the second parameter of CloudRuntimeException please?
|
Looks good, I left only a comment so the exception is not swallowed when an error happens. Happy to merge forward into main as well |
|
|
||
| } catch (Exception e) { | ||
| throw new CloudRuntimeException("Exception caught during resize volume operation of volume UUID: " + volume.getUuid(), e); | ||
| throw new CloudRuntimeException(String.format("Failed to resize volume operation of volume UUID: [%s] due to - %s", volume.getUuid(), e)); |
There was a problem hiding this comment.
@slavkap I think @nvazquez meant you keep e.getMessage() there but also pass exception object as second param of the CloudRuntimeException as it has CloudRuntimeException(String message, Throwable th)
| throw new CloudRuntimeException(String.format("Failed to resize volume operation of volume UUID: [%s] due to - %s", volume.getUuid(), e)); | |
| throw new CloudRuntimeException(String.format("Failed to resize volume operation of volume UUID: [%s] due to - %s", volume.getUuid(), e.getMessage()), e); |
There was a problem hiding this comment.
@shwstppr, thanks! I've misunderstood the comment (sometimes I'm reading selectively... sorry about that)
There was a problem hiding this comment.
NP, @nvazquez, I didn't read your suggestion correctly. Thanks all for testing and code review :)
Will log the exception instead the exception message
295bfe0 to
7cdba5f
Compare
|
Merging based on approvals and test results |
|
@nvazquez do you merge it forward? thanks for that 😄 |
|
@svenvogel sure, it's now included in the main branch as well |
Description
If the volumes are in QCOW2 format, the shrinking will be handled on
the agents' side. There are cases in some storage plugins where the
volumes' format is kept in the DB in QCOW2, but the actual format is raw.
Till the current implementation, this was limiting the plugins to shrink
the volumes. Now this will be handled by the storage plugins.
Types of changes
Bug Severity
How Has This Been Tested?
manual tests with NFS/StorPool primary storages